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1 .0  Introduction 


1.1  Background 


A Generic  Architecture  for  Computer 
integrated  Manufacturing  Software 
Based  on  the  Product  Data  Exchange 

Specification 

The  Product  Data  Exchange  Specification  (PDES)  is  an  emerging 
standard  that  is  intended  to  address  the  problems  of  data  exchange 
and  representation  for  a variety  of  manufacturing  enterprises.  The 
National  Institute  of  Standards  and  Technology  (NIST)  has  a long- 
standing research  program  that  addresses  the  problems  of 
integration  and  development  of  automated  manufacturing  systems. 

This  document  presents  a software  architecture  that  incorporates 
PDES  into  the  software  applications  that  are  part  of  NIST’s  work  in 
Computer  Integrated  Manufacturing  (CIM). 

The  Automated  Manufacturing  Research  Facility  (AMRF)  at  NIST 
is  an  environment  for  the  development,  implementation,  and  testing 
of  CIM  concepts  [Simpson82].  One  aspect  of  the  work  that  has 
been  performed  as  part  of  the  AMRF  project  is  the  sharing  of  data 
between  the  individual  systems  that  contribute  to  the  production  of 
mechanical  parts.  The  AMRF  Part  Model  [Hopp87]  was  conceived 
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1.2  Motivation 

as  a data  representation  that  specified  an  unambiguous  format  for 
description  of  individual  mechanical  parts. 

While  the  AMRF  Part  Model  provided  for  the  exchange  of  part  data 
between  systems  within  the  AMRF,  it  was  never  intended  to  be  a 
universal  solution  to  the  problems  of  product  data  exchange.  It  was 
developed  as  a short  term  solution  to  a long  term  problem  that  was 
not  being  satisfactorily  addressed  by  the  existing  data  exchange 
standards  of  that  time:  notably  the  Initial  Graphics  Exchange 
Specification  (IGES)  [SmithSSa].  As  the  shortcomings  of  IGES  for 
the  purpose  of  data  exchange  in  an  automated  environment  became 
more  apparent  to  industry,  an  international  standards  effort  was 
initiated  to  address  the  problems  of  product  data  representation  and 
exchange.  In  the  United  States,  the  initial  results  of  this  effort  have 
recently  been  published  as  a working  draft:  PDES  Version  1.0 
[SmithSSb].  The  PDES  document  has  reached  draft  proposal 
status  in  the  International  Organization  for  Standardization  (ISO), 
where  it  is  unofficially  known  as  the  Standard  for  the  Exchange  of 
Product  Model  Data  (STEP). 

NIST  is  playing  an  integral  role  in  both  the  coordination  of  the 
various  international  voluntary  committees  that  develop  PDES  and 
in  the  actual  testing  and  validation  of  the  specification. 
Simultaneously,  CIM  research  continues  at  the  AMRF  and  has 
surpassed  the  capabilities  that  the  AMRF  Part  Model  was 
designed  to  fulfill.  As  a result,  there  is  an  immediate  need  to 
incorporate  the  capabilities  of  PDES  into  the  various  systems  of  the 
AMRF.  Doing  so  not  only  advances  the  possibilities  for  research 
in  CIM  in  the  AMRF,  but  also  serves  to  assist  in  the  test  and 
validation  of  PDES. 

The  motivation  for  the  design  of  this  architecture  is  the  need  to 
meet  the  multiple  challenges  of  incorporating  PDES  into  the 

AMRF.  One  of  the  most  formidable  challenges  results  from  the 
instability  of  the  developing  standard.  PDES  is  still  very  much  in 
its  formative  stages,  and  therefore  will  change  in  the  coming  years. 
The  challenge  is  to  create  an  architecture  that  is  easily  adaptable 
to  changes  in  PDES,  in  particular,  one  that  does  not  require  a major 
software  recoding  effort  for  every  change  in  PDES. 

Another  challenge  results  from  the  size  of  the  draft:  currently  it  is 
over  2000  pages  long.  No  single  person  can  possibly  be  an  expert 
in  every  aspect  of  the  standard.  An  application  developer  may  have 
expert  knowledge  in  a few  of  the  subject  areas  contained  in  PDES, 
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but  is  not  usually  an  expert  in  the  techniques  and  terminology  used 
to  represent  that  subject  area  in  the  standard.  The  goal  is  to 
insulate  application  developers  from  the  details  of  PDES  and  its 
implementation,  yet  provide  the  apphcation  with  the  capabihties  it 
requires. 

Finally,  inasmuch  as  PDES  will  be  a single  standard  that 
encompasses  a myriad  of  application  areas,  we  desire  a single 
architecture  based  on  the  standard  that  satisfies  the  needs  of 
related  but  different  software  applications  used  in  conjunction  at  the 
AMRF.  Thus  the  architecture  has  to  be  generic  to  the  environment 
of  the  AMRF  (i.e.,  automated  manufacturing  of  mechanical  parts), 
and  not  specific  to  say,  design  or  inspection  apphcations.  The 
architecture  presented  here  is  intended  to  meet  each  of  these 
challenges. 
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2.0  Description  of 
Architecture 


The  architecture  shown  in  Figure  1 is  structured  into  a multilayer 
design.  The  design  provides  increasing  functionality  from  the 
bottom  layer,  which  consists  of  PDFS  data  representations,  to  the 
top  layer,  where  the  user  interacts  with  an  application.  The  layers 
are  logically  divided  by  functionality,  with  higher  layers  building 
upon  the  functions  of  lower  layers.  The  layered  structure  serves  to 
insulate  higher  level  functions  from  the  details  of  low  level 
representations  and  operations,  while  at  the  same  time  increasing 
maintainability  and  providing  for  expandability. 

An  extremely  important  detail  of  the  software  that  deals  with 
PDFS  is  not  shown  in  the  architecture.  This  is  because  it  is 
essentially  invisible  to  applications  and  users,  thus  it  is  not  of 
direct  concern  to  high  level  developers.  The  function  of  this 
software  is  to  read  the  actual  PDFS  information  model ^ 
specification  which  is  written  in  the  Fxpress^  modeling  language 
[Schenck89].  From  the  information  model  specification,  the 
software  automatically  creates  the  definitions  for  PDFS  data 
structures;  thus  allowing  these  data  structures  to  be  automatically 
updated  whenever  the  PDFS  standard  changes.  Additionally,  other 
highly  useful  software  is  automatically  created  from  the  PDFS 
information  model:  this  includes  the  Low  Level  Access  Functions 
and  parsers  that  are  implicit  in  the  Archive  Creation  and  Retrieval 
Operations  (see  Figure  1).  The  software  that  performs  these 
functions  is  known  as  FedFx;  see  [Clark89]  for  further  information. 

The  following  sections  describe  each  component  of  the  architecture 
and  how  these  components  relate.  Details  of  the  actual 
implementations  are  not  the  focus  here.  Instead  the  aim  is  to  show 
what  functionality  is  provided  and  how  this  functionality  meets  the 
challenge  of  incorporating  PDFS  into  the  AMRF. 


1.  An  information  model  is  a formal  description  of  a collection  of  abstract  con- 
cepts (universe  of  discourse)  which  composes  all  of  the  ideas  to  be  used  by 
systems. 

2.  The  Express  modeling  language  is  a computer-sensible  language  that  was  con- 
ceived as  a mechanism  for  defining  data  objects,  the  behavior  of  data  objects, 
and  the  relationships  between  data  objects  in  PDES. 
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Application  Architecture  Overview 


Figure  1 : Application 
Architecture 
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2.1  Data  Level 


Figure  2:  Representations  in 
the  Data  Level 


2.1.1  Archival  Storage 


2.1 .1.1  Database  Storage 


2.1 .1.2  File  Storage 


The  lowest  level  of  the  architecture  is  the  data  level.  The  data  level 
constitutes  the  actual  computer  representations  of  PDES  models. 


There  are  three  possible  manifestations  of  PDES  models:  a 
database,  a neutral  exchange  file,  and  memory  resident  data 
structures.  Each  of  these  data  representations  are  equivalent  in 
their  PDES  representational  capabilities,  however  their  use  in 
PDES-based  application  software  differs  considerably.  The  three 
representations  are  described  in  the  following  sections. 

Any  PDES  application  needs  to  be  able  to  create  a permanent, 
computer-interpretable  image  of  the  PDES  information  it  has 
created.  Typically,  a computer-readable  data  file  residing  on  disk  or 
tape  storage  media  is  used  as  the  means  for  saving  data.  In 
environments  where  large  amounts  of  data  will  be  shared  frequently 
between  related  applications  and  systems,  a database  can  be 
employed  as  the  means  for  maintaining  permanent  records  of 
application  data.  Since  PDES  will  be  used  both  as  a mechanism  for 
product  exchange  (via  files)  and  as  a structure  for  a shared 
database  [DACOM87]  this  architecture  is  intended  to  support  both 
types  of  archival  storage. 

There  are  many  strategies  possible  for  the  implementation  of  a 
database  in  this  architecture.  The  basic  requirement  we  are 
imposing  on  the  database  is  that  it  be  SQL-compliant  (see  section 
2.2.1).  There  are  many  commercially  available  database  products 
that  could  be  employed  in  the  architecture.  It  will  also  be  possible 
to  incorporate  the  Integrated  Manufacturing  Data  Administration 
System  (IMDAS)  [Libes88]  distributed  database  system 
developed  at  NIST. 

There  are  several  mechanisms  by  which  PDES  model  data  could  be 
represented  in  a neutral  file  format.  The  file  could  be  an  ASCII  text 
file,  a binary  file,  an  encoded/compressed  file,  and  so  on.  Currently, 
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Data  Level 


2.1.2  Working  Form 


the  PDES  working  draft  calls  for  an  ASCII  format  file.  The  mapping 
between  a PDES  information  model  and  a PDES  neutral  exchange 
file  (shown  as  a physical  file  in  Figure  2)  is  specified  in 
[AltemuellerSS]. 

While  the  database  and  physical  file  representations  are  used  as 
archival  storage  mechanisms,  a data  representation  that  resides  in 
computer  memory  is  needed  to  support  efficient  access  to  PDES 
data  by  an  application  ^ When  an  application  is  invoked  using 
PDES  data  stored  in  one  of  the  archives,  the  working  form  data 
structures  will  contain  an  equivalent  representation  of  the  data  that 
was  stored  in  the  archive.  As  the  application  creates  new  data  or 
modifies  the  original  data,  the  modifications  will  exist  only  in  the 
working  form:  the  contents  of  the  working  form  progressively 
diverge  from  the  existing  contents  of  the  archive.  The  contents  of 
the  working  form  are  archived  on  demand  from  the  application  or 
user.  Thus,  consistency  between  archival  storage  and  the  working 
form  is  not  dynamically  maintained;  they  are  consistent  initially 
when  the  working  form  is  loaded  and  thereafter  as  required  by  the 
application  and/or  user. 

Consistency  between  working  forms  and  archival  storage  mediums 
is  by  itself  a non-trivial  issue.  If  we  insist  that  an  application  has 
exclusive  use  of  archival  storage  (a  "single-user"  environment), 
then  consistency  can  be  maintained  by  locking  the  archives  until  the 
application  terminates.  While  simplifying  the  consistency  issue, 
this  restriction  is  not  particularly  desirable  in  a manufacturing 
environment;  i.e.  more  than  one  application  may  require  access  to  a 
given  PDES  model  at  any  given  time  (a  "multi-user"  environment). 
Providing  the  mechanisms  to  support  a multi-use  environment  is  a 
function  that  will  be  addressed  in  the  implementation  of  the 
architecture. 


1.  In  future  architectures,  it  may  be  necessary  to  use  the  database  as  the  work- 
ing form  due  to  the  potentially  large  size  of  PDES  models.  This  will 
require  highly  efficient  database  implementations  and  interfaces  so  as  not  to 
degrade  application  performance. 
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2.2  Representation  Access 

Level 


Figure  3:  Interfaces  to  PDFS 
Data  Representations 


2.2.1  SQL  interface 


2.2.2  File  System 


2.2.3  Working  Form 
Interface 


The  Representation  Access  Level  comprises  the  functions  that 
serve  as  the  interfaces  to  the  PDES  data  representations. 


Functions  at  higher  levels  in  the  architecture  retrieve  PDES  data 
through  these  interfaces.  Each  data  representation  requires  its 
own  particular  interface  mechanism.  The  interfaces  are  described  in 
the  following  sections. 

The  Structured  Query  Language  (SQL)  defines  a set  of  facilities  for 
defining,  manipulating,  and  controlling  data  in  a relational  database 
[Date87].  SQL  has  become  an  internationally  adopted  standard  as 
a procedural  interface  to  relational  databases  [ANSI86].  Adopting 
the  SQL  interface  allows  any  SQL-compliant  database  product  to 
be  incorporated  into  the  architecture.  The  EMDAS  database 
currently  used  in  the  AMRF  provides  an  SQL  interface. 

The  file  system  is  the  interface  to  a physical  file.  For  a given 
computer  system,  the  file  system  is  operating  system  dependent. 
Nonetheless,  we  can  rely  on  the  file  system  to  allow  for  the 
opening,  closing,  creation  and  deletion  of  files  as  well  as  providing 
structured  reading/writing  capabilities  of  the  contents  of  those  files. 
Additionally,  high  level  programming  languages  (e.g.  C,  Lisp,  etc.) 
provide  system-independent  access  to  the  file  system,  yielding  a 
ready-made  interface  to  physical  files. 

The  interface  to  the  working  form  data  structures  is  actually 
comprised  of  two  levels  of  interface  functions;  the  high  and  low  level 
access  functions.  The  motivation  for  separating  the  working  form 
access  functions  in  this  way  is  two-fold.  First,  the  low  level 
functions  are  arcane  and  thus  require  that  the  application  developer 
have  intimate  knowledge  of  the  structure  of  the  PDES  information 
model.  Insulating  the  application  developer  from  the  details  of 
PDES  requires  a second  layer  of  functions  that  group  low  level 
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Representation  Access  Level 


2.2.3.1  Low  Level  Access 
Functions 


2.2.3.2  High  Level  Access 
Functions 


function  calls  into  data  abstractions  that  the  user  is  more 
accustomed  to.  The  second  motivating  factor  for  the  two  sets  of 
functions  is  that  the  low  level  functions  are  independent  of  the  exact 
contents  of  the  PDES  information  model.  Therefore,  as  the  PDES 
information  model  evolves  over  time,  the  low  level  functions  need 
not  be  updated;  however,  the  high  level  functions  do.  Details  of  the 
implementation  of  both  levels  of  functions  will  be  described  in  a 
forthcoming  document. 

The  low  level  access  functions  are  designed  to  be  very  generic  and 
independent  of  the  actual  structure  of  the  PDES  information  model. 
They  are  few  in  number  and  principally  come  in  two  flavors:  query 
functions  and  assignment  functions.  The  query  functions  are  of  the 
form  "Given  an  entity  identification  and  an  attribute  identification, 
what  is  the  value  of  the  attribute?"  Conversely,  the  assignment 
functions  require  the  entity  and  attribute  identifications  and  an 
attribute  value,  then  cause  the  attribute  to  be  assigned  the  given 
value. 

The  high  level  access  functions  are  designed  to  provide  an  abstract 
interface  to  the  detailed  information  found  in  the  PDES  information 
model.  As  in  the  lower  level  functions,  the  high  level  functions  are 
grouped  into  dual  categories:  query  and  assignment  functions.  The 
high  level  query  functions  answer  questions  of  the  form  "What  are 
the  center  vector,  normal  vector,  and  radius  of  the  circle  with  this 
identifier?"  or  "What  are  the  identifiers  of  the  edges  bounding  the 
face  with  this  identifier?"  The  assignment  functions,  of  course, 
provide  the  converse  operation.  The  nature  of  these  high  level 
functions  makes  their  implementation  dependent  upon  the  structure 
of  the  PDES  information  model;  this  is  a drawback.  Considering 
that  the  number  of  functions  useful  at  this  level  is  unbounded,  the 
maintenance  of  these  functions  will  be  a burden  as  PDES  evolves. 
We  have  not  yet  begun  to  look  at  the  possibility  of  automatically 
updating  these  functions  as  PDES  evolves;  it  is  a subject  for  future 
research. 
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2.3  Representation 
Transformation 
Level 


The  Representation  Transformation  Level  encompasses  the 
functions  that  exchange  data  between  the  archival  storage 
representations  and  the  working  form  data  structures.  These 


Figure  4:  Interface  between 
Working  Form  and  Archives 


functions  are  known  collectively  as  the  Archive  Retrieval  & 
Creation  Operations  (see  Figure  4).  Since  there  are  two  archival 
storage  formats,  there  are  two  principal  pieces  in  the  Archive 
Operations.  One  piece  deals  with  the  functions  which  exchange 
data  between  the  working  form  and  the  database  through  the  SQL 
interface.  The  other  piece  deals  with  the  exchange  between  the 
working  form  and  the  physical  file  through  the  File  System 
interface.  This  latter  piece  makes  use  of  a parser  and  an  associated 
report  generator.  Both  of  these  pieces  provide  the  same  facilities 
for  higher  level  functions  in  the  architecture:  that  is,  save  working 
form  to  destination  (where  destination  is  either  the  database  or  a 
physical  file),  and  load  working  form  from  source  (again  either  the 
database  or  a physical  file).  A by-product  of  the  architecture  is  that 
it  is  straightforward  to  create  a physical  file  from  the  contents  of  the 
database  and  to  load  the  database  from  a physical  file. 
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2.4  Application  Resource 

Level 


Figure  5:  Function  Modules 
within  the  Application 
Resource  Level 


2.4.1  Archive  I/O 
Operations 


The  Application  Resource  Level  implements  the  functions  that  are 
considered  useful  across  a broad  spectrum  of  PDES-based 
applications.  Functions  at  this  level  are  able  to  make  calls  to 
functions  at  lower  levels  of  the  architecture  as  well  as  to  functions 
at  the  same  level.  For  example,  the  Feature  & Tolerance 


Application  Resource  Level 


Archive  1 

1 Feature  & 

1 Computational  1 

Graphic 

I/O  1 

1 Tolerance 

1 Geometry  1 

Display 

Operations  | 

1 Operations 

1 Operations  | 

Operations 

To  Archive  Creation  To  Working  Form 

& Retrieval  Operations  Access  Functions 


Operations,  the  Computational  Geometry  Operations,  and  the 
Graphic  Display  Operations  all  rely  on  the  working  form  access 
functions  to  supply  an  interface  to  the  PDFS  data.  The  application 
resource  level  is  not  limited  to  the  modules  shown  in  Figure  5; 
development  of  greater  numbers  of  applications  based  on  PDFS  will 
necessitate  expanded  functionality  in  this  level  of  the  architecture. 
This  level  of  the  architecture  should  be  viewed  as  a software  library 
of  functions  that  are  to  be  used  as  resources  for  developing  specific 
applications. 

The  Archive  I/O  Operations  module  implements  a high  level 
resource  for  the  purpose  of  loading/saving  PDFS  models  ffom/to  the 
different  archival  formats.  This  module  relies  on  the  lower  level 
Creation  and  Retrieval  Operations  to  perform  the  detailed 
transformation  between  archival  storage  and  the  memory  resident 
working  form  data  structures.  It  would  be  possible  for  an 
application  program  to  call  the  lower  level  archive  routines  directly; 
however  doing  so  makes  the  application  program  vulnerable  to 
future  changes  that  will  undoubtedly  take  place  in  the  mapping 
between  PDFS,  the  working  form,  and  the  archival  storage 
formats.  Using  the  archive  routines  at  the  resource  level  isolates 
an  application  from  these  considerations. 
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2.4.2  Feature  & Tolerance 
Operations 


2.4.3  Computational 
Geometry  Operations 


2.4.4  Graphic  Dispiay 
Operations 


The  Feature  and  Tolerance  Operations  module  implements  a high 
level  resource  for  the  purpose  of  manipulating  mechanical  form 
features  and  tolerance  data  in  a PDFS  model.  The  module  provides 
an  application  with  facilities  for  editing  the  relationships,  groupings, 
and  data  necessary  to  define  PDFS  features  and  tolerances  without 
having  to  be  aware  of  the  details  of  the  entity  structures. 

The  Computational  Geometry  Operations  module  implements  a 
high  level  resource  for  the  purpose  of  creating  and  manipulating 
geometry  in  a PDFS  model.  The  module  provides  an  application 
with  facilities  for  establishing  geometry  entities,  for  creating 
geometry  entities  based  on  computations  on  existing  geometric 
entities,  for  computing  the  results  of  geometric  questions,  and  for 
performing  other  related  functions.  Applications  which  make  use  of 
the  functions  provided  in  this  module  do  not  need  to  know  the 
specifics  of  the  implementation  of  PDFS  entities. 

The  Graphic  Display  Operations  module  implements  a high  level 
resource  for  the  purpose  of  producing  and  manipulating  graphical 
visualizations  of  PDFS  models  as  well  as  the  tools  for  building 
graphical  user  interfaces.  Applications  can  invoke  the  utilities 
provided  in  this  module  to  produce  a user  interface  of  their  own 
design  and  graphic  displays  such  as  are  commonly  found  on  modem 
bit-mapped  computer  workstations.  Depending  upon  the 
complexity  of  the  display  desired,  applications  may  need  to  employ 
functions  from  the  computational  geometry  operations  module  for 
display  generation.  Applications  may  also  need  to  devise 
mappings  from  abstract  PDFS  entity  types  to  the  graphics  data 
required  for  displays. 
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2.5  Application  Level 


Figure  6:  Functions  available 
to  software  at  the 
Application  Level 


The  Application  Level  is  the  level  at  which  application- specific 
software  resides.  By  application- specific  software,  we  mean 
software  that  is  intended  to  address  a specific  task,  such  as  design 
or  process  planning,  and  that  intends  to  use  PDES  as  the 
fundamental  data  representation.  With  regard  to  the  work  that  is 
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currently  underway  in  the  AMRF,  the  applications  that  are 
migrating  toward  the  use  of  PDES  include  mechanical  part  design, 
process  planning,  and  inspection  planning.  These  three  applications 
in  particular  will  be  implemented  at  the  Application  level  of  this 
architecture.  As  our  PDES -based  implementations  evolve,  other 
AMRF  applications,  such  as  Equipment  Programming,  may 
incorporate  the  architecture  as  well. 

Software  written  at  the  application  level  has  a rich  collection  of 
functions  available  to  it  for  the  creation,  manipulation,  interrogation, 
and  display  of  PDES  model  data  as  well  as  a number  of  other  highly 
useful  utilities  that  greatly  simplify  application  development.  The 
architecture  thus  follows  the  software  engineering  paradigm  of 
allowing  application  developers  to  concentrate  on  the  task  at  hand 
rather  than  on  a variety  of  background  issues.  Note  that 
Application-specific  software  has  direct  access  to  the  working  form 
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access  functions  in  addition  to  the  functions  provided  in  the 
Application  Resource  Level  (see  Figure  6).  While  we  would  prefer 
that  the  architecture  follow  the  conventions  of  a layered  protocol, 
we  cannot  presume  to  foresee  the  resources  required  by  every 
application  for  its  particular  use  of  PDFS  data.  Therefore  an 
application  can  bypass  the  Application  Resource  Level  to  reach  the 
data  interface  directly.  Naturally,  bypassing  the  Application 
Resource  Level  when  the  resources  of  interest  are  available  there 
is  discouraged. 


Generic  Arch,  for  PDES-based  Software 


Page  14 


James  E.  Fowler 


User  Level 


2.6  User  Level 


Figure  7:  Sample  User 
Interface 


The  User  Level  is  the  level  at  which  a human  user  interacts  with 
the  application  software  residing  at  the  Application  Level.  This 
level  is  included  in  the  architecture  only  for  completeness;  that  is, 
we  are  not  specifying  how  the  user  interface  should  work^  or  even 
in  fact  whether  applications  are  required  to  provide  a user  interface. 
The  aspects  of  a user  interface  are  left  entirely  up  to  the  application- 
specific  software.  Regardless,  provision  is  made  in  the  Application 


Resource  Level  to  facilitate  the  creation  and  maintenance  of  a 
contemporary,  graphical,  window-oriented  user  interface. 


1.  The  subject  of  user  interface  guidelines  has  been  discussed  in  AMRF-related 
projects.  Work  in  this  area  was  presented  at  the  Manufacturing  Data  Prepara- 
tion Project  (MDP)  Workshop  at  NIST  in  June  1988. 
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3.0  Role  of  Off-The- 
Shelf  Software 


3.1  Graphics  Software 


There  are  three  major  areas  in  this  architecture  where  off-the-shelf 
software  can  be  immediately  employed  in  its  implementation. 

These  three  areas  are  the  database,  the  Computational  Geometry 
Operations,  and  Graphic  Display  Operations  modules  in  the 
Application  Resource  Level.  There  are  no  other  opportunities  to 
employ  off-the-shelf  software  in  the  architecture  as  it  has  been 
described  simply  because  no  commercially  available  software 
exists  that  is  compatible  with  PDES.  Using  commercially  available 
software  is  desirable  not  only  because  it  speeds  implementation  of 
the  architecture  but  also  because  it  ameliorates  the  transfer  of  this 
technology  to  industry. 

There  is  not  much  more  to  say  about  the  aspects  of  incorporating 
commercially  available  database  software  than  has  already  been 
covered  in  previous  sections.  Using  commercially  available 
software  in  the  other  two  modules  does,  however,  warrant  futher 
discussion. 

The  Graphic  Display  Operations  module  is  a logical  place  to 
incorporate  off-the-shelf  software.  Functions  such  as  creation, 
manipulation,  and  maintenance  of  graphic  data  and  displays  are 
provided  in  commercially  available  graphics  software  libraries. 

Some  of  these  graphic  libraries  conform  to  the  Programmer’s 
Hierarchical  Interactive  Graphics  System  (PHIGS)  [IS087].  Other 
graphics  libraries  provide  functionality  in  the  spirit  of  PHIGS  but 
may  not  conform  precisely  to  the  standard. 

Aside  from  the  manipulation  of  graphics  data,  the  Graphic  Display 
Operations  module  is  intended  to  provide  functions  for  creating  and 
maintaining  a user  interface.  Software  tools  useful  for  user 
interfaces  include  mechanisms  such  as  windows,  buttons,  and 
menus.  PHIGS  does  not  define  explicit  functions  to  provide  these 
types  of  mechanisms,  although  it  is  conceivable  that  these 
mechanisms  could  be  coded  using  PHIGS  functions,  albeit  with  a 
significant  investment  in  labor.  Fortunately,  there  are  user 
interface  toolkits  available,  notably  X- Windows  [Scheifler86]. 

In  the  best  of  all  worlds,  it  would  be  possible  to  use  a graphics 
library  in  conjunction  with  a user  interface  toolkit  to  provide  most  of 
the  functions  desired  for  the  Graphic  Display  Operations  module. 
Unfortunately,  as  of  this  writing,  not  all  graphics  libraries  cooperate 
with  X-Windows.  In  the  future,  we  presume  that  the  level  of 
integration  between  these  two  highly  useful  and  related  software 
tools  will  increase  (see,  for  example,  PHIGS  Extensions  to  X- 
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Windows  [Rost89]).  In  the  meantime,  the  module  will  be 
implemented  with  available  graphics  libraries  that  do  cooperate 
with  X-Windows,  but  with  sufficient  flexibility  to  adapt  to  future 
developments  in  the  graphics/interface  world. 


3.2  Computational 
Geometry  Software 


The  Computational  Geometry  Operations  module  is  another 
candidate  for  the  incorporation  of  off-the-shelf  software.  Clearly, 
all  three-dimensional  Computer  Aided  Design  (CAD)  systems 
sold  commercially  incorporate  software  functions  that  perform 
operations  such  as  vector  and  matrix  algebra,  compute 
intersections  between  curves  and  surfaces,  etc.  Additionally,  CAD 
systems  that  provide  solid  modeling  operations  must  have 
embedded  software  that  performs  solids  calculations  such  as 
boolean  operations.  Many  of  these  geometric  modeling  functions 
are  specified  in  the  Application  Interface  Specification  (AIS) 
[CAMI86],  which  defines  a method  by  which  application  software 
can  interface  to  a geometric  modeler.  Geometric  modeling  systems 
that  conform  to  AIS  or  a similar  interface  could  be  efficiently 
integrated  into  the  Computational  Geometry  Operations  module. 
The  specific  requirements  for  the  integration  of  an  off-the-shelf 
modeling  system  with  this  architecture  are  found  in  [Fowler89]. 
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4.0  Existing 
Architectures 


4.1  GMAP 


Figure  8:  GMAP  System 
Architecture 


At  this  point,  we  would  like  to  consider  PDES-based  architectures 
that  are  currently  in  existence  and  compare  them  to  the  design  pro- 
posed in  this  paper.  To  the  author’s  knowledge,  there  are  few 
PDES-based  systems  in  existence  [IGES/PDES89],  and  of  the 
known  architectures,  only  one  is  well  documented.  This  system, 
GMAP,  developed  by  Pratt  and  Whitney  for  the  U.S.  Air  Force,  is 
currently  installed  and  available  for  use  at  NIST  [Perlotto89]. 

The  Geometric  Applications  Interface  program  (GMAP)  allows  for 
the  creation  of  PDES  product  model  instances,  and  for  the  develop- 
ment and  evaluation  of  application  programs  based  on  PDES.  A 
simplified  outline  of  the  GMAP  architecture  is  shown  in  Figure  8. 
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As  with  the  architecture  that  is  the  topic  of  this  paper,  a significant 
portion  of  the  GMAP  system  is  not  shown  above:  the  Express 
parser  and  its  associated  software,  known  as  the  Schema  Manag- 
er. The  Schema  Manager  has  the  role  of  defining  the  structure, 
type,  and  access  of  data  in  the  GMAP  system  based  on  information 
parsed  from  the  Express  representation  of  PDES. 

The  functionality  of  the  GMAP  system  compares  to  that  of  the 
NIST  architecture  up  to  the  Representation  Transformation  Level, 
with  one  exception:  the  GMAP  system  lacks  an  interface  to  a data- 
base. Thus,  the  NIST  architecture  and  the  GMAP  system  share 
similar  functionality  for  translating  a physical  file  into  a working 
form  and  back  again.  Both  architectures  also  allow  for  creating,  in- 
terrogating, and  navigating  through  the  model  represented  in  the 
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working  form.  However,  the  combination  of  Model  Access  Soft- 
ware and  NameA^alue  Interface  is  contained  within  the  Low  Level 
Access  Functions  of  the  NIST  system.  The  High  Level  Functions 
have  no  counterpart  in  the  GMAP  system. 

From  an  implementation  standpoint,  the  GMAP  system  is  imple- 
mented in  the  Pascal  programming  language.  The  NIST  system  will 
be  realized  through  the  use  of  SQL,  the  C programming  language, 
and  will  be  accessible  to  LISP-based  applications.  Additionally, 
we  do  not  wish  to  preclude  the  migration  of  the  architecture  to  an 
object-oriented  implementation;  moving  from  a C implementation  to 
a C+-+-  implementation  is  a natural  transition. 
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5.0  Conclusion 


This  document  has  presented  the  design  of  a software  architecture 
that  provides  for  the  efficient  integration  of  PDES  in  the  AMRF.  A 
variety  of  automated  mechanical  part  manufacturing  related 
software  applications  can  be  created  at  the  highest  level  of  the 
architecture,  making  use  of  the  software  tools  at  lower  levels  in  the 
architecture  to  expedite  the  development  of  task  solutions.  High 
level  application  developers  are  largely  insulated  from  the  details  of 
handling  a complicated  and  continuously  evolving  data  standard. 
Finally,  by  allowing  for  the  expeditious  development  of  applications 
based  on  PDES,  we  are  in  turn  promoting  the  development  of  the 
standard  by  providing  a realistic  environment  for  the  test  and 
validation  of  the  standard. 
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